(19) 



(12) 



J 



Europalsches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



I 



(id EP 0 837 579 B1 

EUROPEAN PATENT SPECIFICATION 



(45) Date of publication and mention 
of the grant of the patent: 
12.03.2008 Bulletin 2008/11 



(51) IntCL: 

H04L l2/28( 2006 - 01 > 



(21) Application number: 971 17812.4 

(22) Date of filing: 15.10.1997 



(54) Data transfer control device, relay device and control device suitable for home network 
environment 

Gerat zur Datenubertragungssteuerung, Relaisvorrichtung und Steuerungsvorrichtung fur ein Haus- 
Netzwerk 

Dispositif de commande de transfert de donnees, dispositif relais et dispositif de controle appropries 
pour un reseau domotique 



(84) Designated Contracting States: 
DE FR GBSE 

(30) Priority: 15.10.1996 JP 27267296 

(43) Date of publication of application: 
22.04.1998 Bulletin 1998/17 

(73) Proprietor: KABUSHIKI KAISHA TOSHIBA 
Kawasaki-shi, 

Kanagawa-ken 210-8572 (JP) 

(72) Inventors: 

• Saito, Takeshi 
Inagi-shi, 
Tokyo (JP) 

• Takabatake, Yoshiaki 
Yokohama-shi, 
Kanagawa (JP) 

• Hashimoto, Mikio 
Ichikawa-shi, 
Chiba (JP) 



0Q 

m 

co 
oo 

o 

CL 



(74) Representative: Zangs, Rainer E. et al 
Hoffmann Eitle, 
Patent- und Rechtsanwalte, 
Arabellastrasse 4 
81925 Munchen (DE) 



(56) References cited: 
WO-A-95/27357 



US-A- 5 555 244 



• PATENT ABSTRACTS OF JAPAN vol. 1996, no. 
04, 30 April 1996 (1996-04-30) & JP 07 336642 A 
(CANON INC), 22 December 1995 (1995-12-22) & 
US 6 064 772 A (TANNO ET AL) 16 May 2000 
(2000-05-16) 

• PUNG H K ET AL: "A TCP/IP-X.25 gateway to 
Teleview" SINGAPORE ICCS '94. CONFERENCE 
PROCEEDINGS. SINGAPORE 14-18 NOV. 1994, 
NEW YORK, NY, USA,IEEE, US, vol. 3, 14 
November 1994 (1994-11-14), pages 1164-1168, 
XP010150123 ISBN: 0-7803-2046-8 



Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give 
notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in 
a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 
99(1) European Patent Convention). 



Printed by Jouve, 75001 PARIS (FR) 



1 



EP 0 837 579 B1 



2 



Description 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

[0001 ] The present invention relates to a network sys- 
tem for constructing a home network environment, and 
more particularly, to a data transfer control device, a relay 
device, and a control device suitable for use in the home 
network environment. 

DESCRIPTION OF THE BACKGROUND ART 

[0002] In recent years, there is a rapid trend for dig i- 
talizing electronic instruments as exemplified by the term 
"multi-media", and this trend is already noticeable in the 
office environment. 

[0003] More specifically, in terms of hardware, this 
trend has been materialized in forms of introduction of 
PCs, digitalization of OA devices and formation of net- 
works among them. Also, in terms of software, this trend 
has been expanding to cover the basic functions of hosts 
(which are progressively light-sized and transferred to 
PCs), the application software such as the word-process- 
ing software, the spreadsheet software, etc., and the In- 
ternet application such as the WWW. 
[0004] The similar trend can also be seen in the home 
environment. Namely, even in the home environment, 
this trend for digitalization has been steadily progressed 
in forms of digitalization of AV devices (DVD, digital VTR, 
digital video camera, etc.), digitalization of broadcasting, 
and Internet access such as OCN. 
[0005] Similarly as in a case of the office environment, 
this trend is expected to progress toward the formation 
of networks in future. Namely, it is expected that the tech- 
nologies of various fields such as information processing, 
communication and broadcasting will be unified by the 
digitalization, and inter-mixed with each other by the for- 
mation of networks. 

[0006] There are many candidates for the network 
technologies in this direction. For example, the Ethernet 
has overwhelming records of the actual use in the office 
environment and is probably the most promising candi- 
date even for the home PC network. Also, the ATM is 
another serious contender because of the general con- 
sensus among the infra-structure constructors (tele- 
phone companies, CATV companies, etc.) to keep con- 
structing the infra-structures based on this technology in 
view of the advantageous characteristics of the ATM 
such as its fast, real-time, and wide bandwidth properties. 
[0007] In addition to these candidates, the network 
technology (bus technology) called IEEE 1 394 has been 
attracting much attentions recently. This IEEE 1394 has 
several remarkable characteristics such as its fast, real- 
time (Q0S guaranteed), and plug-and-play properties, so 
that there is a high expectation especially among the AV 
industries on the IEEE 1394 as the most promising can- 



didate for a future scheme for inter-connecting digital AV 
devices. This vogue has also instigated much interests 
to the IEEE 1394 from the computer industries as well. 
[0008] In the initial phase, it is expected that the inter- 

5 connection of the home use digital devices will be realized 
by these various network technologies in conjunction with 
the spread of the home use digital devices, depending 
on preferences and demands of the users, and in this 
way prototype digital networks will be gradually built up 

10 inside each home. 

[0009] In the second phase, there will be demands for 
inter-connecting these digital networks together. For ex- 
ample, there will be a desire to inter-connect an AV device 
connected to the 1394 network of a guest room on the 

15 first floor with another AV device connected to the 1 394 
network of a private room on the second floor in order to 
realize the dubbing orthe cooperative operation between 
these AV devices. 

[0010] However, in order to meet the expected de- 
20 mands of this second phase, the following problems must 
be addressed and resolved. 

[001 1] For now, it is highly likely that many AV devices 
will appear as dedicated 1 394 terminals. This is because 
the infra-structures such as the Internet and B-ISDN are 

25 not yet fully developed so far so that it is presently rather 
difficult to develop any AV device that presupposes the 
availability of these infra-structures. 
[0012] On the other hand, as these infra-structures 
come to be fully developed, it is expected that AV devices 

30 compatible with the Internet or B-ISDN will appear, but 
then it would be difficult to inter-connect such AV devices 
with the by then existing dedicated 1394 terminals. In 
addition, in such a case, only those terminals which are 
connected to the same 1394 as the dedicated 1394 AV 

35 devices would be capable of exchanging AV data and it 
would be impossible to exchange data with nodes which 
are connected to networks other than 1394 or nodes 
which are far distanced. 

[0013] US 6.064.772 discloses an image reproducing 
40 apparatus formed by a personal computer and a related 
method. An ATM network is shown in which various kinds 
of encoded data are transferred, the network comprising 
a line representing a local area network LAN and a line 
representing a local area network in conformity with the 
45 IEEE 1394 standard. Various devices are connected to 
one or more of the different networks such that informa- 
tion can be exchanged. 

[0014] XP 10150123 discloses a TCP/IP - X.25 gate- 
way that bridges the users of computer networks sup- 

50 porting TCP/IP protocol to Teleview via the X.25 public 
data network. The communication architecture shown 
comprises a LAN subscriber, a Teleview gateway, and 
a X.25 router. Information is transferred via the different 
components of the communication network. 

55 [0015] WO 95/27357 relates to the interconnection of 
local communication bus systems and discloses devices 
to interconnectdifferent networks such that receiving and 
transmitting devices can be in communication with each 
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other in spite of the different networks for interconnecting 
the devices. Especially, AV devices are shown which are 
connected to a network which is linked to a second net- 
work via gateways enabling communications therebe- 
tween. 5 

SUMMARY OF THE INVENTION 

[001 6] It is therefore an object of the present invention 
to provide a a relay device, as well as a method for con- 10 
trolling such relay device, capable of resolving the above 
noted problems and suitable for use in the home network 
environment. 

[0017] According to the invention, the above object is 
achieved by providing a relay device comprising the fea- 15 
tures set out in claim 1 . Advantageous embodiments are 
described in the subclaims. Further, according to the in- 
vention, a method achieving the above object comprises 
the steps set out in claim 1 1 . 

[0018] Other features and advantages of the present 20 
invention will become apparent from the following de- 
scription taken in conjunction with the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 25 
[0019] 

Fig. 1 is a blockdiagram showing an exemplary over- 
all configuration of a communication network (home so 
network) according to the first embodiment of the 
present invention. 

Fig. 2 is a block diagram showing an exemplary in- 
ternal configuration of a half gateway in the commu- 
nication network of Fig. 1. 35 
Fig. 3 is a diagram showing one example of a cor- 
respondence table (for a case of transmitting data 
received from a 1 394 side to an ATM side) provided 
in a 1394/ ATM transfer unit of the half gateway of 
Fig. 2. 40 
Fig. 4 is a diagram showing one example of a cor- 
respondence table (for a case of transmitting data 
received from an ATM side to a 1 394 side) provided 
in a 1394/ ATM transfer unit of the half gateway of 
Fig. 2. 45 
Fig. 5 is a sequence chart for an operation sequence 
in a case of transmitting video data from a transmit- 
ting terminal to a receiving terminal in the communi- 
cation network of Fig. 1. 

Fig. 6 is a diagram showing one example of a table 50 
for storing attribute information of information devic- 
es provided in an AV control terminal of the commu- 
nication network of Fig. 1. 

Fig. 7 is a diagram showing one example of a screen 
display by a display device that can be provided in 55 
an AV control terminal of the communication network 
of Fig. 1. 

Fig. 8 is a diagram showing a communication route 



set up in the communication network of Fig. 1 ac- 
cording to the sequence of Fig. 5. 
Fig. 9 is a blockdiagram showing an exemplary over- 
all configuration of a communication network accord- 
ing to the second embodiment of the present inven- 
tion. 

Fig. 10 is a block diagram showing an exemplary 
internal configuration of an AV control terminal in the 
communication network of Fig. 9. 
Fig. 11 is a sequence chart for an operation se- 
quence in a case of transmitting video data from a 
video server to a receiving terminal in the communi- 
cation network of Fig. 9. 

Fig. 1 2 is a diagram showing a communication route 
set up in the communication network of Fig. 9 ac- 
cording to the sequence of Fig. 1 1 . 
Fig. 13 is a block diagram showing another exem- 
plary overall configuration of a communication net- 
work according to the second embodiment,of the 
present invention, which uses an ATM access net- 
work instead of the Internet of Fig. 9. 
Fig. 14 is a block diagram showing an exemplary 
internal configuration of an AV control terminal in the 
communication network of Fig. 13. 
Fig. 15 is a sequence chart for an operation se- 
quence in a case of transmitting video data from a 
video server to a receiving terminal in the communi- 
cation network of Fig. 13. 

Fig. 16 is a block diagram showing another exem- 
plary internal configuration of an AV control terminal 
in the communication network of Fig. 9, which has 
an MPEG decoding unit. 

Fig. 17 is a sequence chart for an operation se- 
quence in a case of transmitting video data from a 
video server to a receiving terminal in the communi- 
cation network of Fig. 9 by using an AV control ter- 
minal of Fig. 1 6. 

Fig. 18 is a block diagram showing an exemplary 
overall configuration of acommunication network ac- 
cording to the third embodiment of the present in- 
vention, for a case of receiving video data from an 
external network at a video terminal on the home 
network. 

Fig. 19 is a sequence chart for an operation se- 
quence in a case of transmitting video data from a 
transmitting terminal (on the Internet) to a receiving 
terminal (on the home network) in the communica- 
tion network of Fig. 18. 

Fig. 20 is a diagram showing a communication route 
set up in the communication network of Fig. 18 ac- 
cording to the sequence of Fig. 19. 
Fig. 21 is a block diagram showing one exemplary 
internal configuration of a half gateway in the com- 
munication network of Fig. 18. 
Fig. 22 is a block diagram showing another exem- 
plary internal configuration of a half gateway in the 
communication network of Fig. 18. 
Fig. 23 is a block diagram showing another exem- 
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plary overall configuration of a communication net- 
work according to the third embodiment of the 
present invention, for a case of transmitting video 
data to an external network from a video terminal on 
the home network. 

Fig. 24 is a block diagram showing an exemplary 
internal configuration of a half gateway in the com- 
munication network of Fig. 23. 
Fig. 25 is a sequence chart for an operation se- 
quence in a case of transmitting video data from a 
transmitting terminal (on the home network) to a re- 
ceiving terminal (on the Internet) in the communica- 
tion network of Fig. 23. 

DETAILED DESCRIPTION OF THE PREFERRED EM- 
BODIMENTS 

<First Embodiment 

[0020] Referring now to Fig. 1 to Fig. 8, the first em- 
bodiment of the present invention will be described in 
detail. 

[0021] Fig. 1 shows an exemplary overall configuration 
of a communication network system according to this first 
embodiment, which constitutes a home network within a 
home, for example. 

[0022] As shown in Fig. 1 , this home network compris- 
es a transmitting terminal 1 , a first AV (Audio Visual) con- 
trol terminal 2, a first half gateway 3, a second half gate- 
way 4. a second AV control terminal 5, a receiving ter- 
minal 6, a first 1 394 bus 1 1 , and a second 1 394 bus 1 2. 
In this embodiment a transmission scheme between the 
half gateways 3 and 4 is assumed to be the ATM. 
[0023] The transmitting terminal 1 and the receiving 
terminal 6 are non-IP terminals (also referred to as 1394 
terminals hereafter), that is, terminals which can only un- 
derstand the 1 394 protocol (a protocol dedicated to 1 394 
such as AV/C protocol and IEC 1883, for example, and 
which cannot understand the Internet Protocol (IP). They 
may be the dedicated 1394 terminals. 
[0024] This first embodiment is directed to a scheme 
of communication between terminals based on a control 
by the AV control terminal, in a case where these trans- 
mitting and receiving terminals are (or one of them is) 
the above described type that cannot understand the In- 
ternet protocol and a direct communication by the 1394 
protocol cannot be carried out between them (such as a 
case where the 1394 buses are not bridge connected, 
that is, a case where a network other than the 1394 bus 
exists between them or a case where the public network 
such as the Internet or the ISDN exists between them). 
[0025] Here, it is assumed that the two 1 394 buses 1 1 
and 12 are not directly bridge connected and the ATM 
network exists between them, so that, on a level of the 
1394 protocol, a dedicated 1394 node connected to one 
1 394 bus cannot see another dedicated 1 394 node con- 
nected to another 1394 bus. 

[0026] In contrast, an IP terminal (also referred to as 



an IP node hereafter) based on the IP which is the inter- 
connection network protocol can recognize the other IP 
terminal connected to another bus even when they are 
terminals connected to these 1394 buses. 

5 [0027] Assuming that the transmitting terminal 1 and 
the receiving terminal 6 are video terminals (as in a case 
where the transmitting terminal 1 is a DVD player and 
the receiving terminal 6 is a TV), for example, and that 
they are provided on the different 1394 buses, the prob- 

10 lem is how to realize a communication between them. 
[0028] Fig. 2 shows an exemplary internal configura- 
tion of each of the half gateways 2 and 3. As shown in 
Fig. 2, the half gateway comprises a 1394 physical 
processing unit 101, a 1394 link processing unit 102, a 

15 first MUX/DEMUX 1 03, an IP/FANP processing unit 1 04, 
a 1394/ATM transfer unit 105, a second MUX/DEMUX 
106, and an ATM interface unit 107. 
[0029] The 1394 physical processing unit 101 and the 
1 394 link processing unit 1 02 carry out the physical layer 

20 processing, the link layer processing, the bus manage- 
ment and the transaction layer processing for a connect- 
ed 1394 bus, as well as the exchanges of data (PDU 
(Protocol Data Unit) from a viewpoint of the 1394) with 
the IP/FANP processing unit 104 or the 1394/ATM trans- 

25 fer unit 105, using the 1394 frames to be transmitted or 
received that are passing through the first MUX/DEMUX 
1 03 and the second MUX/DEMUX 1 06. 
[0030] The IP/FANP processing unit 104 has functions 
for carrying out the routing based on the IP address, the 

30 routing table management, the FANP (Flow Attribute No- 
tification Protocol) processing, the ARP (Address Reso- 
lution Protocol) processing, etc., for the received IP pack- 
ets, FANP packets (which will be described below), ARP 
packets, etc. (For details concerning the FANP, see Jap- 

35 anese Patent Application No. 8-264496 (1 996). 

[0031] The 1394/ATM transfer unit 105 has a function 
for attaching a specific ATM header (VPI/VCI value) to 
data received from the 1394 side, especially data re- 
ceived through the isochronous channel by using its is- 

40 ochronous channel number or as a key or though the 
destination address with the specific register offset by 
using the information as a key, and transmitting it to the 
ATM side, and a function for transmitting data received 
from the ATM side to a specific isochronous channel or 

45 the destination address with the specific register offset 
on the 1 394 side by using its header information (VPI/VCI 
information) as a key. Namely, the data forwarding at this 
processing unit is carried out by using only the datalink 
layer processing. 

50 [0032] For example, a table of correspondence be- 
tween the VPI/VCI value and the channel number of the 
isochronous channel of the 1394 bus or the destination 
address with the specific register offset is produced in a 
form of a correspondence table as shown in Fig. 3 (in a 

55 case of transmitting data received from the 1 394 side to 
the ATM side) or Fig. 4 (in a case of transmitting data 
received from the ATM side to the 1394 side), for exam- 
ple. Here, the mapping (the production of each corre- 
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spondence table) is made by the IP/FANP processing 
unit 104. 

[0033] As for the data forwarding function, this function 
is equipped with a communication quality guarantee 
function by the FANP as will be described below, and the 
data scheduling scheme such as WFQ or WRR, for ex- 
ample, may also be implemented. 
[0034] The ATM interface unit 1 07 is an interface with 
respect to the physically connected ATM network (the 
ATM cable in this embodiment), and carries out the cell 
assembling and disassembling of data to be exchanged 
with the second MUX/DEMUX 106 and the ATM cells. 
This ATM interface unit 1 07 may also carry out the ABR 
(Available Bit Rate) processing, the UPC (Usage Param- 
eter Control) processing, SDH (Synchronous Digital Hi- 
erarchy) processing, etc. 

[0035] Note here that, some VC is defined in advance 
as a default VC of the ATM between the half gateways 
3 and 4, and the both half gateways 3 and 4 already 
recognize that the FANP messages will be exchanged 
through this default VC, as described in Japanese Patent 
Application No. 8-264496 (1996). 

[0036] The first AV control terminal 2 and the second 
AV control terminal 5 are both IP nodes as well as FANP 
nodes and apparently capable of carrying out communi- 
cations by the Internet protocol. As will be described be- 
low, these AV control terminals 2 and 5 can understand 
the 1394 protocol as well as the Internet protocol, and 
are capable of carrying out communications with local 
terminals on the 1 394 bus by using the 1 394 protocol as 
well as communications with local and remote IP termi- 
nals by using the Internet protocol. 
[0037] In the following, it is assumed that the IP nodes 
in Fig. 1 are belonging to the same IP subnet. 
[0038] On each of the AV control terminals 2 and 5, a 
"video transmission and reception control application" is 
implemented. This application has the following func- 
tions. 

(1) A function for checking resources and services 
(such as nodes) on the own local bus, and commu- 
nicating the obtained result with each other by using 
the Internet protocol. 

(2) A function for indicating the resources and serv- 
ices of the terminals on the remote bus to the user 
according to the information obtained by (1), so as 
to urge the user to carry out operations on them, as 
well as exchanging these control information with 
each other. 

(3) A function for exchanging FANP packets with 
each other and reserving a transmission path (a con- 
nection with the bandwidth, etc. reserved, if neces- 
sary) between the 1 394 buses at which the AV con- 
trol terminals are located. 

(4) A function for carrying out the control of nodes 
on the local bus by using the 1394 protocol (such as 
AV/C protocol). 



[0039] By using these AV control terminals, it becomes 
possible for the user to carry out the exchanges of data 
with terminals located on the remote 1394 bus, even 
when transmitting and receiving terminals are not the IP 
5 terminals. 

[0040] The protocol for carrying out the control of AV 
devices on the 1 394 regardless of whether they are local 
ones or remote ones as described above will be called 
a FANP-AV protocol here. This protocol may be an IP 
10 application. 

[0041] For example, consider a case where the first 
1394 bus 11 is provided at a room A within the home 
while the second 1394 bus 12 is provided at a room B 
within the home. Here, suppose that the user who is lo- 
15 cated in the room B tries to display video data from the 
transmitting terminal 1 located in the room A, on the re- 
ceiving terminal 6 located in the room B. 
[0042] Note that these two rooms may not necessarily 
belong to the same home. When they are not, there may 
20 be a public network between the two half gateways 3 and 
4 (in which case they are not necessarily belonging to 
the same IP subnet so that the broadcast described be- 
low may not be carried out and they may recognize each 
other and their addresses by the manual setting). 
25 [0043] Now, with reference to the sequence chart of 
Fig. 5, the operation procedure (including the FANP-AV 
protocol) up to the video data exchange between the 
transmitting terminal 1 and the receiving terminal 6 which 
are the non-IP terminals will be described. 
30 [0044] First, in the communication system of the 
present invention, the user activates the second AV con- 
trol terminal 5 and carries out the necessary setting on 
this second AV control terminal 5. Namely, as shown in 
Fig. 5, the second AV control terminal 5 transmits a 
35 "FANP-AV request" packet to the entire home network, 
i.e. to the IP broadcast address, in order to check the 
presence/absence of a node for processing the FANP- 
AV protocol on the home network (step S1). 
[0045] This packet is assigned with a well known port 
40 number which is allocated to the FANP-AV processing 
function in advance. This IP broadcast packet may be 
transmitted to a 1394 address called "bus broadcast ad- 
dress" on the second 1394 bus 12, that is, to the asyn- 
chronous channel in a form of broadcast with respect to 
45 all nodes in the home network of that home. This broad- 
cast packet reaches to all nodes on the second 1 394 bus 
1 2. Note here that it is also possible to transmit this packet 
to a 1394 address called "local bus broadcast" as long 
as it is made such that this packet reaches to all nodes 
50 within that IP subnet. Namely, even when a networkother 
than the 1 394 bus is connected, it is sufficient if it is made 
such that this packet will be transferred. 
[0046] Now, the second half gateway 4 that received 
this packet confirms that it is "broadcast with respect to 
55 all buses" from the destination 1394 address, and for- 
wards this packet to the first half gateway 3 side. The 
first half gateway 3 that received this packet then for- 
wards this packet to the first 1394 bus 1 1 (step S2). At 
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this point, the destination 1 394 address is the "bus broad- 
cast address". 

[0047] Here, a node which by itself is activating the 
FANP-AV protocol receives this packet (FANP-AV re- 
quest packet), and confirms that it is the "FANP-AV re- 
quest", that is, a packet for searching a node that is ac- 
tivating the FANP-AV protocol, by referring to the port 
number. Then, this node transmits a "FANP-AV re- 
sponse" packet indicating that "it is also activating the 
FANP-AV protocol" as a response to the received packet, 
to its source IP address (step S3). In Fig. 5, the first AV 
control terminal 2 is the FANP-AV protocol node, so that 
this terminal transmits the FANP-AV response packet to 
the second AV control terminal 5 which is the source of 
the "FANP-AV request" packet. At the same time, the 
first AV control terminal 2 stores the existence of the sec- 
ond AV control terminal 5 and its IP address. 
[0048] Note that, as already noted above, instead of 
carrying out such an automatic constituent recognition, 
it is also possible for the AV control terminals to recognize 
each other by using a method in which each AV control 
terminal registers addresses of the other AV control ter- 
minals by the manual setting in advance. 
[0049] Around this point, each FANP-AV node (AV 
control terminal 2, 5) collects information on AV devices 
existing on the 1394 bus to which it is connected, by using 
the 1394 protocol (step S4 and step S5). This operation 
may be realized by using protocols such as the AV/C 
protocol and the IEEE 1212 which are standardized by 
the 1394 trade association and the HD-DVTR confer- 
ence, or their extended versions. 

[0050] In this manner, each AV control terminal 2, 5 
collects various information regarding AV devices on the 
1394 bus to which it belongs, such as what AV devices 
they are, what contents they have, how many media they 
have, what 1394 addresses they have, etc., and store 
the collected information into an internal table. 
[0051] Next, the AV control terminals 2 and 5 exchange 
the collected information with each other (step S6). For 
this information exchange, each one transmits the col- 
lected information to the IP address of the other by using 
IP packets. As a result, in each AV control terminal 2, 5, 
a table with contents as shown in Fig. 6 is produced, for 
example. Namely, by carrying out this information ex- 
change between the AV control terminals 2 and 5, each 
AV control terminal 2, 5 can collect various information 
(attribute information) regarding AV devices which are 
connected with a network to which the other AV control 
terminal belongs, such as what AV devices they are, what 
contents they have, how many media they have, what 
1394 addresses they have, etc., in addition to the infor- 
mation regarding AV devices on the 1394 bus to which 
it belongs, on the table of Fig. 6. 

[0052] It is also possible to display the information on 
the table of Fig. 6 at a display screen of the AV control 
terminal 2, 5. Fig. 7 shows an exemplary screen display 
by a display device provided at the second AV control 
terminal 5. In Fig. 7, for the sake of clarity, under the 



assumption of one bus per one room (or one datalink 
networkperone room), display windows (W1 to W4) with- 
in the display screen are set in correspondence to the 
respective rooms, and the screen display is presented in 

5 a form of an arrangement in each room. By looking at 
this, the user can make a judgement such as "to/from 
which terminal should data be transmitted/received". 
[0053] For example, suppose that the user in the room 
B wishes to receive video data from the transmitting ter- 

10 minal 1 and display it on the receiving terminal 6. To this 
end, the user operates the second AV control terminal 5 
so as to make a setting by which appropriate contents 
constituting the video at the transmitting terminal 1 are 
transmitted to the receiving terminal 6 and displayed 

15 there. This operation may be carried out through the GUI 
on the second AV control terminal 5. In response, the 
second AV control terminal 5 transmits an instruction with 
a content of "send appropriate contents constituting the 
video at the transmitting terminal 1 to the receiving ter- 

20 minal 6" to the first AV control terminal 2 (step S7). By 
means of this, the first AV control terminal 2 can ascertain 
the address of the transmitting terminal 1 which is the 
transmission destination in a form of the 1394 address. 
[0054] The first AV control terminal 2 that received this 

25 instruction communicates with the transmitting terminal 
1 by the 1394 protocol, and checks whether the video 
transmission is possible or not. In addition, the operation 
such as the authentication with respect to the second AV 
control terminal 5 may also be carried out. 

30 [0055] Next, the first AV control terminal 2 reserves 
the isochronous channel of the first 1 394 bus 1 1 by using 
the 1394 protocol and the 1394 AV protocol, etc., at the 
first 1394 bus 1 1 (step S8). A channel number reserved 
at this point is assumed to be #X (the isochronous chan- 

35 nel 31 of Fig. 8). Also, as should be apparent, the band- 
width necessary for the video transmission is to be re- 
served at the same time by acting on the isochronous 
resource manager of the first 1 394 bus 1 1 . 
[0056] Next, the first AV control terminal 2 makes a 

40 setting with respect to the first half gateway 3 so that the 
isochronous channel #X will be received there. Then, the 
first AV control terminal 2 transmits the offer message of 
the FANP toward the first half gateway 3 through this 
isochronous channel (step S9). 

45 [0057] Here, the FAN P is the protocol described in Jap- 
anese Patent Application No. 8-264496 as already noted 
above. Namely, this protocol is used for the purpose of 
carrying out communications with a neighboring node 
that can interpret the FANP (which is usually provided at 

50 a middle of network segments that constitute the home 
network and plays a role of an inter-connection device 
for these plurality of segments), and notifying the identi- 
fier of the channel through which data are to be transmit- 
ted, their destination address, and their communication 

55 attribute and communication quality. It is also possible 
to use this protocol for the purpose of setting up an end- 
to-end connection. 

[0058] Now, this offer message conveys a channel 
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number (or a virtual channel identifier, etc.) by which data 
(a video data in this embodiment) are to be transmitted 
from now on, a destination address (an IP address in this 
embodiment) of that video data, the bandwidth to be used 
(communication quality), the communication attribute 
(such as a coding scheme like MPEG, etc.), an end-to- 
end ACK request, etc. Note that when the transmission 
channel number or virtual channel identifier is notshared 
by the terminals at both ends, the exchange of the pro- 
pose message and the propose ACK message of the 
FANP may be exchanged between these ends. Also, the 
destination address (target IP address) of that data is the 
IP address of the second AV control terminal. 
[0059] The first half gateway 3 that received this offer 
message confirms that the second AV control terminal 5 
exists in a direction of the second half gateway 4 by re- 
ferring to the internal routing table, and checks whether 
it is possible to support the bandwidth, communication 
quality, etc. requested by this offer message by referring 
to the idle bandwidth, etc., of acommunication path inside 
the second half gateway 4. When it is judged that it is 
possible to support them, the propose message, the pro- 
pose ACK message, the offer message, etc., are trans- 
mitted to the second half gateway 4 similarly as in the 
above processing. On the other hand, when it is judged 
that it is not possible to support them, a reject message 
is transmitted to the first AV control terminal 2. 
[0060] The second half gateway 4 checks the internal 
communication resources (checks whether the commu- 
nication quality described in the offer message is inter- 
nally possible or not similarly as in the first half gateway 
3), and establishes the isochronous channel #Y (the is- 
ochronous channel 33 of Fig. 8) on the second 1394 bus 
12. Around this point, the second half gateway 4 com- 
mands the second AV control terminal 5 to take the con- 
tents of this isochronous channel, by using the 1 394 pro- 
tocol. After that; the exchanges of the propose message, 
the propose ACK message and the offer message are 
carried out between the second half gateway 4 and the 
second AV control terminal 5 (step S1 1 ). 
[0061 ] The second AV control terminal 5 that received 
the propose message and the offer message recognizes 
that they are for the video transmission earlier requested 
by this second Av control terminal 5 to the first AV control 
terminal 2, according to the flow I Dor the prescribed iden- 
tifier agreed by both sides in advance. This prescribed 
identifier can be that which is conveyed by the FANP 
message. 

[0062] Next, the second AV control terminal 5 com- 
mands the receiving terminal 6 to receive the data trans- 
mitted through the isochronous channel #Y, by using the 
1394 protocol such as IEC 1883 (step S12). By means 
of this, the data transmitted through the isochronous 
channel #Y can be received by the receiving terminal 6. 
[0063] After that, the second AV control terminal 5 
transmits the re-direct message to the second half gate- 
way 4 (step S13). This re-direct message is a message 
that bears the meaning that the setting offered by the 



offer message of the step S1 1 is accepted. When the 
offer message contains the end-to-end ACK request, the 
re-direct message is transmitted by setting the end-to- 
end ACK flag ON (where setting the end-to-end ACK flag 
5 ON implies that a route for transmitting the video data 
from the transmitting terminal 1 to the receiving terminal 
6 has been set up). This ACK flag reaches to the trans- 
mitting terminal (the first AV control terminal 2 in this em- 
bodiment). 

10 [0064] The second half gateway 4 that received this 
re-direct message makes an appropriate setting to the 
internal 1394/ ATM transfer unit 105 (more specifically 
the setting of the corresponding table such as that shown 
in Fig. 3 or Fig. 4). Namely, the ATM virtual connection 

15 32 (shown in Fig. 8) offered by the offer message at the 
step S9 and the isochronous channel #Y are switch con- 
nected at the datalink layer. More specifically, at the 
1394/ATM transfer unit 105, the ATM cells entered from 
the ATM virtual connection 32 are transferred to the 1394 

20 data and entered into the isochronous channel #Y, by 
referring to the VCI value directly, without any processing 
by the IP/FANP processing unit 104. At this point, the 
data/packet scheduling scheme in which the communi- 
cation quality defined by the FANP can be maintained 

25 may be selected. Note that the, correspondence table in- 
side the 1394/ATM transfer unit 105 which is to be re- 
ferred at this point is that shown in Fig. 3 or Fig. 4. 
[0065] The re-direct message returns from the second 
half gateway 4 to the first half gateway 3 (at which the 

30 setting of the 1394/ATM transfer unit 105 is made simi- 
larly as in the second half gateway 4), and then to the 
first AV control terminal 2 (step S14). 
[0066] Here, the first AV control terminal 2 confirms 
that the datalink layer connection up to the final terminal 

35 asshown in Fig. 8 has been setup. Here, thefinalterminal 
is the receiving terminal 6 in this embodiment, but the 
receiving terminal 6 is the dedicated 1394 terminal and 
not a node that can understand the FANP and the IP. It 
is the second AV control terminal 5 that made the prep- 

40 aration such that the receiving terminal 6 can receive the 
video data, and the setting was made by this second AV 
control terminal 5 by using the 1394 protocol. 
[0067] Then, the first AV control terminal 2 commands 
the transmitting terminal 1 to carry out the transmission 

45 of the corresponding appropriate video with respect to 
the isochronous channel with the channel number #X 
(the isochronous channel 31 of Fig. 8), by using the 1 394 
protocol (step S15). 

[0068] The transmitted video reaches to the receiving 
50 terminal 6 through the isochronous channel 31 on the 
first 1 394 bus 1 1 , the ATM virtual connection 32, and the 
isochronous channel 33 on the second 1 394 bus 1 2 (step 
S16). At the intermediate nodes (the half gateways 3 and 
4), only the switching in the datalink layer is applied, so 
55 that the data transfer is carried out by maintaining the 
communication quality while the data pass through this 
route. 

[0069] The transmission of the re-direct message for 
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the purpose of connecting, this video transmission is car- 
ried out from the second AV control terminal 5 toward 
the upstream side (that is, through the second half gate- 
way 4 and the first half gateway 3, to the first AV control 
terminal 2) (step S17). 

[0070] Also, a request for interruption of the transmis- 
sion from the user side (the transmission of the release 
message) is also sent from the second AV control termi- 
nal 5 in thesimilarly order. Atthis point, the first AV control 
terminal 2 carries out the control by the 1394 protocol 
such as AV/C protocol toward the transmitting terminal 
1 so as to terminate the video transmission. 
[0071] As described, according to the communication 
network system of this embodiment, the control of AV 
devices over a plurality of 1 394 buses such as the video 
delivery, interruption, etc., from the transmitting terminal 
1 to the receiving terminal 6 is carried out by the FANP 
and the FAN P-AV, despite of the fact that the transmitting 
terminal 1 and the receiving terminal 6 are not the IP 
terminals (that is, through the AV control terminals 2 and 
5). 

[0072] In general, the implementation of the IP is said 
to be costly, but by using the scheme of the present in- 
vention, the control between AV devices in which the IP 
is not implemented and the control of connection over a 
plurality of 1 394 buses can be carried out by the AV con- 
trol terminals 2 and 5 in which the IP and the FANP are 
implemented, so that a simplification, a low cost imple- 
mentation, and a centralized control can be realized for 
the system as a whole. In addition, it should be apparent 
that the same can be realized by exactly the same prin- 
ciple even when a plurality of FANP nodes exist between 
the half gateways. Consequently, it becomes possible to 
carry out the control between AV terminals on arbitrary 
1394 buses, without requiring a long distance 1394 bus 
transfer or a complicated 1 394 bridge protocol which are 
the drawbacks of the 1394 buses. 
[0073] Note that, in this embodiment, it is assumed that 
the AV control terminals 2 and 5 carry out communica- 
tions with each other by using the IP, but it is also possible 
to realize this feature by using the other network layer 
technology (such as Netware. CLNP (Connection-Less 
Network Protocol), etc.) or the other technology such as 
l-PNNI (Integrated P-NNI), instead of the IP. 
[0074] Also, in this embodiment, the set up of the con- 
nection (channel) between the AV control terminals 2 and 
5 is made by using the protocol called FANP, but it is 
easily possible to realize this feature by using the other 
connection set up protocol such as RSVP (Resource 
Reservation Protocol), ST2 (Stream Transport Protocol- 
2), or l-PNNI, instead of the FANP. 
[0075] Also, in this embodiment, it is assumed that the 
network to which the transmitting terminal 1 and the re- 
ceiving terminal 6 are connected is the IEEE 1394 bus, 
but it is also possible to use FDDI2 or the broadcast based 
network such as home ATM-LAN as described in Japa- 
nese Patent Application No. 8-108015 (1996), in sub- 
stantially the same manner as described above. Moreo- 



ver, it is also possible to use a network which is not broad- 
cast based, by modifying the AV control terminal to also 
carry out the connection set up between the half gate- 
ways and the transmitting/receiving terminals in a man- 

5 ner of the third party set up. 

[0076] Also, in this embodiment, it is assumed that the 
AV control terminal 2, 5 and the half gateway 3, 4 are 
provided in separate bodies, but they may be provided 
within the same body. Namely, when the AV control ter- 

10 minal 2 and the half gateway 3 are provided in an identical 
body while the AV control terminal 5 and the half gateway 
4 are provided in an identical body, it is possible to regard 
the half gateways 3 and 4 themselves as incorporating 
the functions of the AV control terminals 2 and 5. 

15 [0077] Also, in this embodiment, a scheme in which 
the information regarding AV devices on local buses is 
exchanged between the AV control terminals 2 and 5 has 
been described, but when a number of AV control termi- 
nals increases, this information exchange may be carried 

20 out by using mesh connections among the AV control 
terminals. It is also possible to use a scheme in which 
one AV control terminal functioning as a server distrib- 
utes the information to the other AV control terminals, or 
the hybrid of these schemes in which some AV control 

25 terminal aggregates the information for a plurality of AV 
control terminals and notifies the aggregated information 
to the other AV control terminals. 

[0078] Also, in this embodiment, when the user is op- 
erating the AV control terminal, the resulting control proc- 
30 ess may be displayed on a display device provided at 
the receiving terminal 6. 

<Second Embodiment 

35 [0079] Referring now to Fig. 9 to Fig. 17, the second 
embodiment of the present invention will be described in 
detail. 

[0080] This second embodiment is directed to a case 
where the end-to-end data transmission is controlled by 

40 the signaling protocol of the network layer such as RSVP, 
ST2, etc., and the data exchanges with a network of that 
network layer are to be carried out. 
[0081] Fig. 9 shows an exemplary overall configuration 
of a communication network system according to this 

45 second embodiment, In Fig. 9, an AV control terminal 
1 1 03 is connected to the Internet 1 1 02 (or arbitrary net- 
work), and connected with a receiving terminal 1105 
through a 1394 bus 1 104. Then, the video data delivery 
from a video server 1 1 01 connected to the Internet 1 1 02 

50 is to be carried out with respect to the receiving terminal 
1 105, for example. 

[0082] The video server 1 101 is the Internet terminal 
which transmits the video data on IP packets, that is, in 
the format of MPEG-over-IP. For example, this video 
55 server 1101 may carry out the transmission of the TS 
(Timestamp) of the MPEG by RTP. 
[0083] The AV control terminal 1 1 03 is connected be- 
tween the Internet 1 1 02 and the 1 394 bus 1 1 04, and has 
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functions for carrying out a control to the Internet 1102 
side, a control to the 1 394 bus 1 1 04 side, and transmitting 
data from one network to another network by matching 
communications from both. This AV control terminal 1 1 03 
may be provided in a form of a unit called set-top box. 
[0084] The receiving terminal 1 1 05 is a non-l P terminal 
that can understand the 1 394 protocol only, which carries 
out the video data reception. Consequently, the reception 
of MPEG data must obey the data format of MPEG-over- 
1 394 as defined by the I EC 1 883, for example. 
[0085] As described above, in this embodiment, it is 
assumed that the video data transfer from the video serv- 
er 1 101 is realized by the transmission in the format of 
MP EG -over- IP through the Internet 1 102. In order to car- 
ry out this video data transmission by maintaining the 
communication quality while being in the Internet 1102, 
the communication quality is guaranteed by the RSVP 
inside the Internet 1 1 02. Here, of course, the guarantee 
may be made by the ST2 or the FANP, although this 
embodiment describes a case of using the RSVP. 
[0086] Now, aprocedurefortransmittingthe videodata 
from the video server 1 1 01 to the receiving terminal 1 1 05 
which is not the IP terminal in the communication network 
system of Fig. 9 will be described. 
[0087] Fig. 1 0 shows an exemplary internal configura- 
tion of the AV control terminal 1 1 03. As shown in Fig. 1 0, 
the AV control terminal 1 1 03 comprises an external net- 
work interface unit 1201, a first MUX/DEMUX 1202, an 
RSVP processing unit 1203, a 1394 AV processing unit 
1204, an MPEG-over-IP/MPEG-over-1394 conversion 
unit 1205, a second MUX/DEMUX 1206, and a 1394 in- 
terface unit 1207. 

[0088] The external network interface unit 1201 is an 
interface with respect to the Internet 1 102, which is an 
interface on the datalink layer and the physical layer in 
particular, and which transmits the received data to the 
RSVP processing 1203 or the MPEG-over-IP/MPEG- 
over-1394 conversion unit 1205 through the first MUX/ 
DEMUX 1202 according to the need. 
[0089] The RSVP processing unit 1 203 has a function 
for reserving a route that guarantees the communication 
quality between the AV control terminal 1 1 03 and an ar- 
bitrary terminal (the video server 1101 in this embodi- 
ment) connected to the Internet 1 1 02 by carrying out the 
RSVP processing, and a function for carrying out the IP 
processing. 

[0090] The 1394 AV processing unit 1204 has a func- 
tion for carrying out the processing of the 1394 AV pro- 
tocol (AV/C protocol. IEC 1883, etc.) or the FANP-AV 
protocol described in the first embodiment, through the 
1394 bus 1104. 

[0091] The MPEG-over-IP/MPEG-over-1394 conver- 
sion unit 1205 has a function for converting the MPEG 
frames entered from the Internet 1 1 02 in the MPEG-over- 
IP format into the MPEG-over-1 394 format and transmit- 
ting them. Of course, it may also has a function for con- 
verting in the opposite direction. This format conversion 
may be carried out by referring to the source address, 



destination address, port number, flow labels, etc., of the 
arrived IP packet, or in a case where the Internet is the 
virtual connection type network, this format conversion 
may be carried out by referring to the virtual channel iden- 
5 tifier or channel number, etc. In this embodiment, the 
processing of the latter case will be described as an ex- 
ample. 

[0092] The 1 394 interface unit 1 207 is an interface with 
respect to the 1 394 bus 1 1 04, and more specifically, has 
10 functions for carrying out the physical layer processing, 
the link layer processing, the transaction layer processing 
and the bus management. 

[0093] The AV control terminal in a configuration 
shown in Fig. 1 0 is for a case where the receiving terminal 
15 1105 has the MPEG reproduction function (MPEG de- 
coding function). In addition, the AV control terminal 1 1 03 
may also have a function (including analog circuits, etc.) 
generally called set-top box. 

[0094] The user acts on the AV control terminal 1 1 03 
20 when the user wishes to receive the video data from the 
video server 1101 at the receiving terminal 1 1 05. Name- 
ly, the user makes the setting with respect to the AV con- 
trol terminal 1 1 03, as to which video should be sent from 
which video server and at which receiving terminal it 
25 should be received (watched). 

[0095] At this point, instead of requiring the user to act 
directly on the AV control terminal 1 1 03, the system may 
have a configuration in which, when the user acts on the 
other terminal, a control message is sent from that other 
30 terminal to the AV control terminal so as to request a 
subsequent series of control operations. 
[0096] The AV control terminal 1 1 03 requests the vid- 
eo data transmission to the video server 1 101 which is 
the IP node, by using the IP protocol. This operation may 
35 be realized through a protocol such as HTTP. Also, this 
operation may be realized in a form in which the control 
protocol such as DSM-CC defined by the ITU-T and DAV- 
IC flows over the Internet. 

[0097] At this point, it is also possible to use a scheme 
40 in which the PATH message of the RSVP is flowing from 
the video server 1 1 01 and the AV control terminal 1 1 03 
sends the RESV message of the RSVP in response so 
as to establish a route guaranteeing the QOS between 
the video server 1 1 01 and the Av control terminal 1 1 03 
45 (step S101 of Fig. 11). 

[0098] In addition, the AV control terminal 1 1 03 estab- 
lishes, the isochronous channel (channel number #X) on 
the 1394 bus with respect to the receiving terminal 1 1 05, 
and transmits a message for commanding the reception 
50 of data from this isochronous channel by using the 1 394 
protocol such as I EC 1 883, AV/C protocol, or 1 394-1 995 
(step S102 and step S103 of Fig. 11). 
[0099] Along with that, the setting of the MPEG-over- 
IP/MPEG-over-1394 conversion unit 1205 is made, that 
55 is, the setting by which a packet in the MPEG-over-IP 
format entered from the Internet 1102 is taken out ac- 
cording to its header information (an identifier of the da- 
talink layer connection through which this packet passes, 
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or the IP header information, or the flow label, etc.), con- 
verted into the data format of the MPEG-over-1394, and 
transmitted to the prescribed isochronous channel #X 
(the isochronous channel 1111 of Fig. 12) on the 1394 
bus 1104 (step S104). This setting may be made in a 
form which guarantees the communication quality such 
as jitter or delay time. 

[0100] By means of this, a route 1110 and 1111 (a 
route with the communication quality guaranteed) from 
the video server 1101 to the receiving terminal 1 1 05 as 
shown in Fig. 12 is reserved. 

[0101] Here, the MPEG packet among the packets that 
passed through the Internet 1102 is forwarded to the 
MPEG-over-IP/MPEG-over-1394 conversion unit 1205, 
and an information for triggering the format conversion 
there may be the VPI/VCI value that carries this MPEG 
data, when the access datalink of the Internet 1102 is 
the ATM, for example. In this case, there is no need to 
bring this processing up to the IP layer. 
[01 02] Also, when the access datalink is the STM net- 
work, the format conversion may be triggered by an input 
from its channel number/specific time-slot, etc. In this 
case, there is no need to bring this processing up to the 
IP layer either. 

[0103] Also, the format conversion may be triggered 
by using a part of the header information of the IP packet 
(such as "destination address + port number", the flow 
label of the IPv6, etc.). 

[0104] The MPEG data are transmitted from the video 
server 1 101 in the format of MPEG-over-IP, so that the 
AV control terminal 1 1 03 converts them into the MPEG- 
over-1394 format at the MPEG-over-IP/MPEG-over- 
1394 conversion unit 1205 and then transmits them to 
the receiving terminal 1105 (step S105). 
[0105] In this manner, the reception of the video data 
transmitted by the IP can be realized even atthe receiving 
terminal which is not the IP terminal (the receiving termi- 
nal 1 105 in this embodiment). 

[0106] Note that the 1394 bus 1104 portion may be 
replaced by a group of bridge connected 1 394 buses, or 
a network formed by mixed networks of the 1 394 buses 
and other networks in which the 1394 bus is emulated. 
[0107] It is also possible to use the ATM access net- 
work as the access network to the home instead of the 
Internet 1102. Fig. 13 shows an exemplary overall con- 
figuration of the communication network system in such 
a case, which differs from Fig. 9 in that the Internet 1 1 02 
of Fig. 9 is replaced by an ATM access network 1502. 
[01 08] Note that, in this case, in Fig. 1 3, the AV control 
terminal 1503 and/or the video server 1501 may be the 
ATM terminal (a terminal that can understand and proc- 
ess only the ATM-API), so that the exchange between 
the AV control terminal 1503 and the video server 1501 
will involve the call set up by the ATM signaling, etc. 
[01 09] Fig. 14 shows an exemplary internal configura- 
tion of the AV control terminal 1 503. As shown in Fig. 1 4, 
the format conversion is made between the MPEG-over- 
ATM format and the MPEG-over-1394 format at the 



MPEG-over-ATM/MPEG-over-1394 conversion unit 
1605. Here, the MPEG-over-ATM format may be in a 
form according to the protocol defined by the AMS of the 
ATM forum. 

5 [0110] The call set up by the ATM signaling between 
the AV control terminal 1503 and the video server 1501 
is to be carried out at an ATM signaling processing unit 
1603. 

[01 11] The functions of the other elements of Fig. 14 

10 are the same as those of Fig. 1 0. 

[01 12] Fig. 15 shows a sequence chart for the opera- 
tions of the communication network system of Fig. 13 as 
a whole. Fig. 15 differs from Fig. 11 in that the virtual 
connection (VCI = #X) for carrying out the call set up by 

15 the ATM signaling is established at a time of establishing 
a route between the video server 1 501 and the AV control 
terminal 1503 at the step S201 of Fig. 15 (which corre- 
sponds to the step S101 of Fig. 11). The other parts of 
Fig. 15 are substantially the same as Fig. 1 1 . 

20 [0113] Note that, in this embodiment, an example in 
which the network inside the home is formed by the 1 394 
bus has been described, but the scheme of the present 
invention is equally applicable to a case where the net- 
work inside the home is not the 1394 bus but the other 

25 network technology (such as the ATM, etc.). 

[01 1 4] The above embodiment is directed to an exem- 
plary case in which the MPEG decoder is provided at the 
receiving terminal side. However, it is also possible to 
consider a case in which the MPEG decoder does not 

30 exist on the receiving terminal side and the receiving ter- 
minal only has a function for receiving the raw video data 
directly and displaying them. 

[0115] In such a case, in the communication network 
system of Fig. 9, for example, instead of carrying out the 

35 format conversion at the AV control terminal 1 103, it is 
also possible to use a configuration in which, as shown 
in Fig. 1 6, an MPEGdecoding unit 1 805 is provided inside 
the AV control terminal 1 1 03 and the MPEG decoding is 
carried out inside the AV control terminal 1 103 for the 

^0 MPEG-over-IP data (or the MPEG-over-ATM data, etc.) 
entered into the AV control terminal 1 103. and the raw 
video data after the MPEG decoding are transmitted to 
the receiving terminal 1 1 05 through the 1 394 bus 1 1 04. 
Fig. 17 shows the operation sequence in this case. 

45 Namely, Fig. 1 7 differs from Fig. 1 1 in that the step S1 04 
to S1 05 of Fig. 1 1 are replaced by the step S1 1 1 to S1 1 3 
in Fig. 1 7. where the format conversion is not carried out 
but the MPEG decoding of the MPEG-over-IP data (or 
the MPEG-over-ATM data, etc.) is carried out at the 

50 MPEG decoding unit 1805 and the raw video data are 
transmitted to the receiving terminal 1105 through the 
isochronous channel #X on the 1394 bus 1104 (step 
S111 to step S1 13 of Fig. 17). 

[01 16] By means of this, the high level functions such 
55 as the MPEG decoding are concentrated to the AV con- 
trol terminal 1 103, so that there is a merit in that a load 
on the receiving terminal 1 105 can be reduced. 
[01 17] Also, Fig. 9 uses the Internet between the video 
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server 1101 and the AV control terminal 1103, but the 
scheme of the present invention is of course not limited 
to a case of using the Internet and equally applicable to 
a case of using the other network configuration such as 
ATM network, SDH network, FTTH, etc. 5 
[0118] Note that, as a configuration of the AV control 
terminal 1 103. it is also possible to consider a configu- 
ration which is capable of processing a plurality of MPEG 
streams simultaneously. In this case, it is also possible 
to adopt the processing scheme in which the different 10 
processings are applied to different streams, as in a case 
of applying the MPEG decoding to one MPEG stream 
while applying the format conversion from the MPEG- 
over-IP to the MPEG-over-1394 to another MPEG 
stream, for example. In such a case, it suffices to provide 15 
a plurality of MPEG decoders, MPEG encoders, or con- 
version units inside the AV control terminal 1 103. 

<Third Embodiment 

20 

[0119] Referring now to Fig. 18 to Fig. 25, the third 
embodiment of the present invention will be described in 
detail. 

[0120] Fig. 1 8 shows an exemplary overall configura- 
tion of a communication network system according to this 25 
third embodiment. As shown in Fig. 1 8, the communica- 
tion network system of the third embodiment comprises 
a router 2001, a first half gateway 2002, a second half 
gateway 2003, an AV control terminal 2004, a video ter- 
minal 2005, an Internet 201 1 , a first 1 394 bus 201 2, and 30 
a second 1394 bus 2013. 

[0121] In Fig. 18, a network formed by the router 2001 
and elements on the right side of the router 2001 (that 
is, the router 2001 , the first 1394 bus 2012, the first half 
gateway 2002, the second half gateway 2003, the second 35 
1394 bus 2013, the AV control terminal 2004, and the 
video terminal 2005) may be a home networkconstructed 
within the home. 

[0122] Also, in this embodiment the video terminal 
2005 is a non-IP terminal, similarly as in the first embod- 40 
iment. 

[0123] Here, a case of receiving video data (assumed 
to be transmitted in the MPEG-over-IP format) from a 
VideoServer (notshown) on the Internet201 1 atthe video 
terminal 2005 which is the non-IP terminal will be con- 45 
sidered. 

[01 24] Note that it is the AV control terminal 2004 that 
directly negotiate with the Internet or the video server by 
the IP, similarly as in the second embodiment. 
[0125] This third embodiment differs from the second 50 
embodiment in that it is the second half gateway 2003 
rather than the AV control terminal 2004 that carries out 
the control of transfer from the MPEG-over-IP to the 
MPEG-over-1394. Here, the control of transfer may be 
carried out by the first half gateway 2002 or the router 55 
2001 instead of the second half gateway 2003, but a case 
where the control of transfer is carried out by the second 
half gateway 2003 will be described in this embodiment. 



[01 26] To this end, the AV control terminal 2004 is con- 
nected with the second 1394 bus 2013, but unlike the 
first embodiment, it is not absolutely necessary for this 
AV control terminal 2004 to be located on a path from 
the Internet 201 1 to the video terminal 2005. 
[0127] Also, here, the second half gateway 2003 may 
appear as a set-top box from a viewpoint of the video 
terminal 2005. 

[01 28] Also, in this embodiment, the bandwidth control 
between the subnets of the Internet (that is, at a boundary 
between one IP subnet and another IP subnet) is to be 
carried out by the RSVP, and the FANP described in the 
first embodiment is to be used within the subnet (that is, 
a portion of the elements on the right side of the router 
2001 ). Consequently, the router 2001 and the AV control 
terminal 2004 are RSVP nodes while the router 2001, 
the first half gateway 2002, the second half gateway 
2003, and the AV control terminal 2004 are FAN P nodes. 
[0129] The transmission scheme between the half 
gateways 2002 and 2003 is assumed to be the ATM sim- 
ilarly as in the first embodiment. 

[0130] Now, with reference to Fig. 19, the video data 
transmission sequence will be described. 
[0131] A user who wishes to receive the video trans- 
mitted from the Internet at the video terminal 2005 makes 
a program request by operating the AV control terminal 
2004 similarly as in the second embodiment. Here, an 
actual operation screen may be displayed on a display 
device provided in the video terminal 2005. Also, at a 
time of this reservation, the reservation of the communi- 
cation resources using the RSVP may also be carried 
out in order to receive the video program at a high com- 
munication quality. Consequently, the reservation of the 
communication resources by using an RESV message 
of the RSVP is carried out with respect to a PATH mes- 
sage of the RSVP transmitted from the Internet 201 1 side 
(step S201 ). Note that the half gateways 2002 and 2003 
are not the RSVP nodes so that the RSVP messages 
simply pass through them. 

[0132] The router 2001 that received the RESV mes- 
sage reserves the connection and the communication 
resources on a route from the router 2001 to the AV con- 
trol terminal 2004 by using the FANP described in the 
first embodiment. At this point, the fact that data to be 
transferred by the FANP are MPEG data may be notified 
to each node. 

[0133] Here, suppose that the reserved communica- 
tion resources includes, as shown in Fig. 20, an iso- 
chronous channel 2202 on the first 1 394 bus, a connec- 
tion 2203 between the half gateways 2002 and 2003, and 
an isochronous channel 2204 on the second 1394 bus. 
Here, the isochronous channel 2204 on the second 1 394 
bus is the broadcast on the second 1394 bus because 
of the property of the 1394 bus. 

[01 34] Now, the AV control terminal 2004 receives the 
FANP offer message transmitted from the router 2001 
(step S202). and returns the FANP re-direct message 
(step S203) so as to permit the connection establishing. 
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Also, around this point, the following two operations are 
carried out by the AV control terminal 2004. 
[01 35] The first operation is to command the video ter- 
minal 2005 to receive the isochronous data at the iso- 
chronous channel 2204, by using the 1 394 protocol (step 
S204). By means of this, a state in which a connection 
with the communication quality guaranteed is estab- 
lished from the router 2001 to the video terminal 2005 of 
Fig. 20 is substantially realized. 

[01 36] The second operation of the AV control terminal 
2004 is to command the second half gateway 2004 to 
carry out the format conversion from the MPEG-over-IP 
to the MPEG-over-1394 (step S205). Here, the MPEG- 
over-1 394 format may be a format defined by I EC 1 883, 
etc. In this case, the fact that the second half gateway 
2003 has the transfer function in advance may be already 
recognized by the AV control terminal 2004, or some pro- 
tocol for the purpose of checking the presence/absence 
of the transfer function may run through the network. 
[01 37] This transfer command may be made in a form 
of the IP application, or in a form of the 1394 application. 
For this reason, the second half gateway 2003 has an 
internal function for transferring from the MPEG-over- IP 
to the MPEG-over-1394 (the MPEG-over-1 394/MPEG- 
over-IP conversion unit 2304 of Fig. 21 ). 
[0138] The internal configuration of the second half 
gateway 2003 shown in Fig. 21 differs from the internal 
configuration of the half gateway in the first embodiment 
in that the MPEG-over-1 394/MPEG-over-IP conversion 
unit 2304 is included in the second half gateway 2003, 
and thatthe I P/FANP processing unit 2303 has a function 
for making a setting of the MPEG-over-1 394/MPEG- 
over-IP conversion unit 2304 according to a "transfer 
command" signal at the step S205 in the sequence of 
Fig. 19, so that the format conversion from the MPEG- 
over-IP to the MPEG-over-1394 will be carried out for 
appropriate input IP packets on which the MPEG data 
are mounted. 

[0139] Now, the RESV message of the RSVP that 
reached to the router 2001 flows further to an upstream 
side and reaches to the video server (now shown) (step 
S206). At this point, the end-to-end connection with the 
communication quality guaranteed is established from 
the video server to the video terminal 2005 as shown in 
Fig. 20. Here, prior to the video data transmission, some 
notification signal (asignalfor urging the video data trans- 
mission) may be sent from the AV control terminal 2004 
to the video server. 

[0140] After that, the transmission of the video data 
from the video server is started (step S207). The video 
data pass through the connection set 2201 on the IP of 
Fig. 20, and reaches to the video terminal 2005 through 
the connections 2202, 2203 and 2204 established by the 
FAN P. Note here that the format conversion from the 
MPEG-over-IP format to the MPEG-over-1394 format is 
carried out at the second half gateway 2003. 
[0141] The above description is directed to a case 
where the video terminal 2005 has the MPEG decoder. 



In contrast, in a case where the video terminal 2005 does 
not have the MPEG decoder and is in a configuration for 
receiving and reproducing the raw video data, it is also 
possible to use a configuration in which the MPEG de- 

5 coder is provided in the second half gateway 2003 so 
that the MPEG decoding from the MPEG-over-IP is car- 
ried out and the obtained raw video data are transmitted 
to the video terminal 2005. In this configuration, there is 
no need to implement the expensive MPEG decoder in 

10 the video terminal 2005, so that there is a merit in that a 
construction of a low cost system becomes possible. 
[01 42] Fig. 22 shows an exemplary internal configura- 
tion of the second half gateway 2003 in this case. This 
configuration of Fig. 22 differs from that of Fig. 21 in that 

15 the MPEG decoder unit 2404 is provided instead of the 
MPEG-over-1 394/MPEG-over-IP conversion unit 2304 
of Fig. 21. 

[0143] At the MPEG decoder unit 2404, the MPEG de- 
coding may be carried out when a command signal for 
20 commanding the decoding of the MPEGdata issentfrom 
the AV control terminal 2004 to the second half gateway 
2003. 

[0144] Here, in a case of carrying outthe MPEG format 
conversion orthe MPEG decoding, the format conversion 

25 or decoding processing may be carried out by implicitly 
recognizing that data contents are MPEG data from the 
value of the datalink identifier (VPI/VCI value in a case 
of the ATM, for example) between the two half gateways 
2002 and 2003, without carrying outthe IP layer process- 

30 jng. In this manner, it is possible to start the MPEG format 
conversion processing or the MPEG decoding process- 
ing by omitting the IP processing which is generally said 
to be costly, so that the quick processing and the low 
cost can be realized simultaneously. 

35 [0145] Note that, as should be apparent, the system 
in such a configuration is applicable not only to a case 
of receiving video from the Internet but also to a case of 
the video data transmission by the MPEG-over-ATM 
when the access network is the ATM network as in the 

40 second embodiment, or to cases using any other trans- 
mission schemes. 

[0146] Also, the transmission of video data (or data in 
general) is not necessarily limited to the MPEG, and any 
coding scheme can be used. 
45 [0147] Also, the above operations can be utilized for 
the information transmission from the home. Namely, in 
the communication network system with a configuration 
as shown in Fig. 23, consider a case of transmitting the 
raw video data or MPEG data from the transmitting ter- 
50 minal 3001 which is the non-IP terminal. 

[0148] Basically, it suffices to carry out the sequence 
opposite to that of the receiving described above (see 
the sequence shown in Fig. 25). Namely, the AV control 
terminal 3002 establishes a connection up to the receiv- 
es ing terminal by the signaling protocol of the network layer 
(step S301 ), transmits the isochronous channel number, 
etc., to the router 3005 by the FANP, offer message (step 
S302), and receives the re-direct message from the rout- 
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er 3005. 

[0149] Also, the AV control terminal 3002 commands 
the transmitting terminal 3001 to transmit data through 
the earlier set up isochronous channel, by using the 1394 
protocol (step S304), and in addition a command for 5 
transfer (or MPEG encoding) is sent from the AV control 
terminal 3002 to the first half gateway 3303 for example 
(step S305). 

[0150] By means of this, when the MPEG encoder unit 
3404 as shown in Fig. 24 (in a case where the MPEG 10 
encoder is not provided in the transmitting terminal 3002) 
or the function of the format conversion from the MPEG- 
over-1394 to the MPEG-over-IP (the MPEG-over- 
1394/MPEG-over-IP conversion unit 2304) as shown in 
Fig. 21 is provided at the first half gateway 3003, it be- 15 
comes possible to carry out the data transmission from 
the transmitting terminal 3001 (step S306). 
[0151] Note that, by incorporating the MPEG encoder 
unit 3404 (for encoding video data transmitted from the 
1394 side toward the ATM side) of the half gateway in 20 
the configuration shown in Fig. 24 into the half gateway 
in the configuration shown in Fig. 22 so that the MPEG 
encoder and the MPEG decoder are provided simulta- 
neously, it becomes possible to carry out the bi-direction- 
al communications by a single device (half gateway). It 25 
is obviously also possible to use this device in such a 
manner that two or more uni-directional communications 
are carried out simultaneously and the encoder and the 
decoder are used for the respective communications in- 
dependently. 30 
[01 52] It is also possible to consider a configuration in 
which the MPEG encoding function, the MPEG decoding 
function, and the MPEG format conversion function are 
provided separately, and necessary ones of these func- 
tions are executed by the mode switching according to 35 
an appropriate control signal from the AV control terminal 
3002. 

[0153] It is also possible to consider a configuration 
which is capable of processing a plurality of MPEG 
streams simultaneously. In this case, it is also possible 40 
to adopt the processing scheme in which the different 
processings are applied to different streams, as in a case 
of applying the MPEG decoding to one MPEG stream 
while applying the format conversion from the MPEG- 
over-IP to the MPEG-over-1394 to another MPEG 45 
stream, for example. 

[0154] As described, according to the present inven- 
tion, it becomes possible for the dedicated IEEE 1394 
terminal to carry out communications with a group of 
nodes which are operated by the protocol other than the 50 
IEEE 1394, and it also becomes possible to inter-connect 
the IEEE 1394 buses through a physical network other 
than the IEEE 1394 bus. 

[01 55] It is to be noted that, besides those already men- 
tioned above, many modifications and variations of the 55 
above embodiments may be made without departing 
from the novel and advantageous features of the present 
invention. Accordingly, all such modifications and varia- 
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tions are intended to be included within the scope of the 
appended claims. 

Claims 

1 . A relay device fortransmitting and receiving contents 
data between at least one terminal device (1) con- 
nected to afirst network (1 1 ) and at least one terminal 
device (8) connected to a second network (12), the 
relay device being connected to the first network (1 1 ) 
and the second network (12) and comprising: 

a reception unit (3) configured to receive the 
contents data transmitted from the transmitting 
terminal (1); and 

a transmission unit (4) configured to transmit the 
contents data received by the reception unit (3) 
to the receiving terminal (6); 

characterized by 

a first collection unit (2) configured to collect an ad- 
dress and attribute information of each terminal de- 
vice connected to the first network (1 1 ), by inquiring 
at least one of a type of the each terminal device and 
the contents data possessed by the each terminal 
device, and the attribute information containing the 
address of the each terminal device; 
a second collection unit (5) configured to collect the 
address and the attribute information of each termi- 
nal device connected to the second network (1 2), by 
inquiring at least one of a type of the each terminal 
device and the contents data possessed by the each 
terminal device, and the attribute information con- 
taining the address of the each terminal device; 
a memory unit (2, 5) configured to store the address 
and the attribute information of each terminal device 
on the first network (1 1 ) and the second network (1 2) 
collected by the first collection unit (2) and the second 
collection unit (5); 

a display control unit (2, 5) configured to enable dis- 
play of information stored in the memory unit (2, 5); 
a first set up unit (2, 3) configured to set up a con- 
nection for transmitting contents data to be transmit- 
ted from a transmitting terminal (1) to a receiving 
terminal (6), on the first network (1 1 ), upon receiving 
a request for transmission of the contents data pos- 
sessed by the transmitting terminal (1 ) from a termi- 
nal device on the first network (11) selected as the 
transmitting terminal (1) to a terminal device on the 
second network (12) selected as the receiving ter- 
minal (6) according to the display of information en- 
abled by the display control unit (2, 5), such that the 
reception unit (3) receives the contents data trans- 
mitted from the transmitting terminal (1 ) by using the 
connection; and 

a second set up unit (4, 5) configured to set up a 
channel for transmitting the contents data to be 
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transmitted from the transmitting terminal (1 ), on the 
second network (12), such that the transmission unit 
(4) transmits the contents data received by the re- 
ception unit (3) to the receiving terminal (6) by using 
the channel. 5 

2. The relay device of claim 1 , further comprising: 

a display unit (2, 5) configured to display the 
information stored in the memory unit (2, 5) ac- 10 
cording 

to the display control unit (2, 5). 

3. The relay device of claim 1 , further comprising: 

15 

A decoding unit (3) configured to decode encod- 
ed contents data received by the reception unit 
(3), 

wherein the transmission unit (4) transmits the con- 20 
tents data decoded by the decoding unit (3) to the 
receiving terminal (6) by using the channel. 

4. The relay device of claim 1 , wherein the first network 
(11) is an IEEE 1394 bus, and the channel is an IEEE 25 
1394 isochronous transfer channel. 

5. The relay device of claim 4, wherein the IEEE 1394 
bus that constitutes the first network (11) is formed 

by bridge connections of a plurality of IEEE 1394 so 
buses. 

6. The relay device of claim 1 , further comprising: 

a command unit (2) configured to command the 35 
transmitting terminal (1 ) to transmit the contents 
data by using the connection, when the channel 
is set up on the second network (12) by the sec- 
ond set up unit (4, 5) according to a control mes- 
sage received by the relay device; the control 40 
message containing at least information regard- 
ing a required amount of communication re- 
sources at a time of transmitting the contents 
data on the second network (12) and a header 
information to be attached to the contents data, 45 
in order to set up the channel on the second 
network (12). 

7. The relay device of claim 1 , wherein the request for 
transmission of the content data possessed by the 50 
transmitting terminal (1) is made by a request mes- 
sage containing information for identifying the trans- 
mitting terminal (1 ) such that the transmission of the 
contents data is commanded to the transmitting ter- 
minal (1) identified by this information. 55 

8. The relay device of claim 1 , further comprising: 



a command unit (5) configured to command the 
receiving terminal device (6) to receive the con- 
tents data to be transmitted by using the channel 
when the channel is set up by the second set up 
unit (4, 5). 

9. The relay device of claim 1 , wherein the second net- 
work (12) is an IEEE 1394 bus, and the channel is 
an IEEE 1394 isochronous transfer channel. 

10. The relay device of claim 9, wherein the IEEE 1394 
bus that constitutes the second network (12) is 
formed by bridge connections of a plurality of IEEE 
1394 buses. 

1 1 . A method for controlling a relay device for transmit- 
ting and receiving contents data between at least 
one terminal device connected to a first network and 
at least one terminal device connected to a second 
network, the relay device being connected to the first 
network and the second network and the method 
comprising: 

receiving the contents data transmitted from the 
transmitting terminal, and 
transmitting the contents data received by the 
receiving step to the receiving terminal; 

characterized by 

collecting an address and attribute information of 
each terminal device connected to the first network, 
by inquiring atleaseoneof atypeof the eachterminal 
device and the contents data possessed by the each 
terminal device, and the attribute information con- 
taining the address of the each terminal device; 
collecting the address and the attribute information 
of each terminal device connected to the second net- 
work, by inquiring at least one of a type of the each 
terminal device and the contents data possessed by 
the each terminal device, and the attribute informa- 
tion containing the address of the each terminal de- 
vice; 

storing the address and the attribute information of 
each terminal device on the first network and the 
second network collected by the collecting steps in 
a memory; 

enabling display of information stored on the mem- 
ory; 

setting up aconnection for transmitting contents data 
to be transmitted from a transmitting terminal to a 
receiving terminal, on the first network, upon receiv- 
ing a request for transmission of the contents data 
possessed by the transmitting terminal from a termi- 
nal device on the first network selected as the trans- 
mitting terminal to a terminal device on the second 
network selected as the receiving terminal according 
to the display of information enabled by the enabling 
step, such that the receiving step receives the con- 
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tents data transmitted from the transmitting terminal 
by using the connection; and 

setting up a channel for transmitting the contents da- 
ta to be transmitted from the transmitting terminal, 
on the second network, such that the transmitting 5 
step transmits the contents data received by the re- 
ceiving step to the receiving terminal by using the 
channel. 

10 

Patentanspruche 

1 . Relaisvorrichtung zum Senden und Empfangen von 
Inhalte-Daten zwischen mindestens einer mit einem 
ersten Netz (11) verbundenen Endgeratevorrich- 15 
tung (1) und mindestens einer mit einem zweiten 
Netz (1 2) verbundenen Endgeratevorrichtungen (8), 
wobeidie Relaisvorrichtung mitdem ersten Netz (1 1 ) 
und dem zweiten Netz (12) verbunden ist und um- 
fasst: 20 

eine Empfangseinheit (3), konfiguriert zum 
Empfangen von dem sendenden Endgerat (1) 
gesendeten Inhalte-Daten; und 
eine Sendeeinheit (4), konfiguriert zum Senden 25 
von den durch die Empfangseinheit (3) empfan- 
genen Inhalte-Daten zu dem empfangenden 
Endgerat (6); 

gekennzeichnet durch so 

eine erste Sammeleinheit (2), die konfiguriert ist zum 
Sammeln einer Adress- und Attributinformation je- 
der mit dem ersten Netz (1 1 ) verbundenen Endge- 
ratevorrichtung durch Abfragen mindestens eines 
von einem Typ der jeweiligen Endgeratevorrichtung 35 
und den Inhalte-Daten, die die jeweilige Endgerate- 
vorrichtung besitzt, und der die Adresse der jeweili- 
gen Endgeratevorrichtung enthaltenden Attributin- 
formation; 

eine zweite Sammeleinheit (5), konfiguriert zum 40 
Sammeln der Adress- und Attributinformation jeder 
mit dem zweiten Netz (1 2) verbundenen Endgerate- 
vorrichtung durch Abfragen von mindestens einem 
von einem Typ der jeweiligen Endgeratevorrichtung 
und den Inhalte-Daten, die die jeweilige Endgerate- 45 
vorrichtung besitzt, und der die Adresse der jeweili- 
gen Endgeratevorrichtung enthaltenden Attributin- 
formation; 

eine Speichereinheit (2, 5), konfiguriert zum Spei- 
chern der Adress- und Attributinformation der jewei- 50 
ligen Endgeratevorrichtung in dem ersten Netz (1 1) 
und dem zweiten Netz (12), gesammelt durch die 
erste Sammeleinheit (2) und die zweite Sammelein- 
heit (5); 

eine Anzeigesteuereinheit (2, 5), konfiguriert zum 55 
Zulassen des Anzeigens von in der Speichereinheit 
(2, 5) gespeicherter Information; 
eine erste Einrichteeinheit (2, 3), konfiguriert zum 



Einrichten einer Verbindung zum Senden von von 
einem sendenden Endgerat (1 ) zu sendenden Inhal- 
te-Daten zu einem empfangenden Endgerat (6) in 
dem ersten Netz (1 1 ) auf das Empfangen einer An- 
frage zum Senden der Inhalte-Daten, die das sen- 
dende Endgerat (1 ) besitzt, von einer Endgeratevor- 
richtung des ersten Netzes (1 1 ), die als das senden- 
de Endgerat (1 ) ausgewahltworden ist, zu einer End- 
geratevorrichtung des zweiten Netz (12), die als das 
empfangende Endgerat (6) ausgewahlt worden ist, 
in Ubereinstimmung mit dem durch die Anzeige- 
steuereinheit (2, 5) zugelassenen Anzeigen von In- 
formation derart, dass die Empfangseinheit (3) die 
von dem sendenden Endgerat (1 ) gesendeten Inhal- 
te-Daten unter Verwendung der Verbindung emp- 
fangt; und 

eine zweite Einrichteeinheit (4, 5), konfiguriert zum 
Einrichten eines Kanals zum Senden der von dem 
sendenden Endgerat (1) zu sendenden Inhalte-Da- 
ten in dem zweiten Netz (12) derart, dass die Sen- 
deeinheit (4) die von der Empfangseinheit (3) emp- 
fangenen Inhalte-Daten zu dem empfangenden 
Endgerat (6) unter Verwendung des Kanals sendet. 

2. Relaisvorrichtung nach Anspruch 1 , ferner umfas- 
send: 

eine Anzeigeeinheit (2, 5), konfiguriert zum An- 
zeigen der in der Speichereinheit (2, 5) gespei- 
cherten Information in Ubereinstimmung mit der 
Anzeigesteuereinheit (2, 5). 

3. Relaisvorrichtung nach Anspruch 1 , ferner umfas- 
send: 

eine Decodiereinheit (3), konfiguriert zum De- 
codieren codierter, von der Empfangseinheit (3) 
empfangener Inhalte-Daten, wobei die Sender- 
einheit (4) die Inhalte-Daten decodiert durch die 
Decodiereinheit (3) zu dem empfangenden End- 
gerat (6) unter Verwendung des Kanals sendet. 

4. Relaisvorrichtung nach Anspruch 1 , wobei das erste 
Netz (11) ein IEEE-1 394-Bus ist und der Kanal ein 
isochroner IEEE-1394-Ubertragungskanal ist. 

5. Relaisvorrichtung nach Anspruch 4, wobei der IEEE- 
1 394-Bus, der das erste Netz (1 1 ) bildet, durch Brid- 
ge-Verbindungen einer Vielzahl von IEEE-1394- 
Bussen gebildet wird. 

6. Relaisvorrichtung nach Anspruch 1, ferner umfas- 
send: 

eine Befehlseinheit (2), konfiguriert, um dem 
sendenden Endgerat (1) zu befehlen, Inhalte- 
Daten unter Verwendung der Verbindung zu 
senden, wenn der Kanal im zweiten Netz (12) 
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durch die zweite Einrichteeinheit (4, 5) einge- 
richtet worden ist in Ubereinstimmung mit einer 
Steuernachricht, die von der Relaisvorrichtung 
erhalten wird; 

5 

wobei die Steuernachricht mindestens Information 
in Bezug auf einen erforderlichen Umfang an Kom- 
munikationsressourcen zu einer Zeit des Sendens 
der Inhalte-Daten in dem zweiten Netz (12) enthalt 
und eine Header-Information, die zu den Inhalte-Da- 10 
ten hinzuzufugen ist, um den Kanal im zweiten Netz 
(12) einzurichten. 

7. Relaisvorrichtung nach Anspruch 1, wobei die An- 
forderung nach dem Senden der Inhalte-Daten, die 15 
das sendende Endgerat (1) besitzt, durch eine An- 
forderungsnachricht vorgenommen wird, die Infor- 
mation zum Identifizieren des sendenden Endgerats 

(1 ) derart umfasst, dass das Senden der Inhalte-Da- 
ten dem sendenden Endgerat (1), das durch diese 20 
Information identifiziert wird, befohlen wird. 

8. Relaisvorrichtung nach Anspruch 1, ferner umfas- 
send: 

25 

eine Befehlseinheit (5), konfiguriert, um der 
empfangenden Endgeratevorrichtung (6) zu be- 
fehlen, die zu sendenden Inhalte-Daten unter 
Verwendung des Kanals zu empfangen, wenn 
der Kanal durch die zweite Einrichteeinheit (4, so 
5) eingerichtet worden ist. 

9. Relaisvorrichtung nach Anspruch 1 , wobei das zwei- 
te Netz (12) ein IEEE-1394-Bus ist und der Kanal 

ein isochroner IEEE-1394-Ubertragungskanal ist. 35 

1 0. Relaisvorrichtung nach Anspruch 9, wobei der I EEE- 
1394-Bus, der das zweite Netz (12) bildet, durch 
Bridge-Verbindungen einer Vielzahl von IEEE-1394- 
Bussen gebildet wird. 40 

1 1 . Verfahren zum Steuern einer Relaisvorrichtung zum 
Senden und Empfangen von Inhalte-Daten zwi- 
schen mindestens einer mit einem ersten Netz ver- 
bundenen Endgeratevorrichtung und mindestens ei- 45 
ner mit einem zweiten Netz verbundenen Endgera- 
tevorrichtung, wobei die Relaisvorrichtung mit dem 
ersten Netz und dem zweiten Netz verbunden ist und 
das Verfahren umfasst: 

50 

Empfangen der von dem sendenden Endgerat 
gesendete Inhalte-Daten, und 
Senden der durch den Empfangsschrittempfan- 
genen Inhalte-Daten zu dem empfangenden 
Endgerat; 55 

gekennzeichnet durch 

Sammeln einer Adress- und Attributinformation je- 



der mit dem ersten Netz verbundenen Endgerate- 
vorrichtung durch Abfragen von mindestens einem 
von einem Typ der jeweiligen Endgeratevorrichtung 
und den Inhalte-Daten, die die jeweilige Endgerate- 
vorrichtung besitzt, und der die Adresse der jeweili- 
gen Endgeratevorrichtung enthaltenden Attributin- 
formation; 

Sammeln der Adress- und Attributinformation jeder 
mit dem zweiten Netz verbundenen Endgeratevor- 
richtung durch Abfragen von mindestens einem von 
einem Typ der jeweiligen Endgeratevorrichtung und 
den Inhalte-Daten, die die jeweilige Endgeratevor- 
richtung besitzt, und der die Adresse der jeweiligen 
Endgerateeinrichtung enthaltenden Attributinforma- 
tion; 

Speichern der in dem Sammelschritte gesammelten 
Adress- und der Attributinformation der jeweiligen 
Endgeratevorrichtung in dem ersten Netz und dem 
zweiten Netz, in einem Speicher; 
Zulassen des Anzeigens von in dem Speicher ge- 
speicherter Information; 

Einrichten einer Verbindung zum Senden von von 
einem sendenden Endgerat zu einem empfangen- 
den Endgerat zu sendenden Inhalte-Daten in dem 
ersten Netz auf das Empfangen einer Anforderung 
furdas Senden der Inhalte-Daten, die das sendende 
Endgerat besitzt, von einer Endgeratevorrichtung im 
ersten Netz, die als das sendende Endgerat ausge- 
wahlt worden ist, zu einer Endgeratevorrichtung im 
zweiten Netz, die als das empfangende Endgerat 
ausgewahlt worden ist, in Ubereinstimmung mit dem 
Anzeigen von durch den Zulassungsschritt zuge- 
lassener Information, derart, dass der Empfangs- 
schritt die von dem sendenden Endgerat unter Ver- 
wendung der Verbindung gesendeten Inhalte-Daten 
empfangt; und 

Einrichten eines Kanals zum Senden der von dem 
sendenden Endgerat zu sendenden Inhalte-Daten 
in dem zweiten Netz derart, dass der Sendeschritt 
die von dem Empfangsschritt empfangenen Inhalte- 
Daten zu dem empfangenden Endgerat unter Ver- 
wendung des Kanals sendet. 



Revendications 

1 . Dispositif relais en vue de transmettre et de recevoir 
des donnees de contenu entre au moins un dispositif 
terminal (1 ) connecte a un premier reseau (1 1 ) et au 
moins un dispositif terminal (8) connecte a un second 
reseau (1 2), le dispositif relais etant connecte au pre- 
mier reseau (11) et au second reseau (12) et 
comportant : 

une unite de reception (3) configuree en vue de 
recevoir les donnees de contenu transmises par 
le terminal de transmission (1) ; 
une unite de transmission (4) configuree en vue 
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de transmettre les donnees de contenu recues 
par I'unite de reception (3) au terminal de recep- 
tion (6) ; 

caracterise par 5 

une premiere unite de collecte (2) configuree en vue 
de collecter des informations d'adresses et d'attri- 
buts de chaque dispositif terminal connecte au pre- 
mier reseau (1 1 ), en demandant au moins I'un d'un 
type de chaque dispositif terminal et les donnees de 10 
contenu possedees par chaque dispositif terminal, 
et les informations d'attributs contenant I'adresse de 
chaque dispositif terminal ; 

une seconde unite de collecte (5) configuree en vue 
de collecter les informations d'adresses et d'attributs 15 
de chaque dispositif terminal connecte au second 
reseau (12), en demandant au moins I'un d'un type 
de chaque dispositif terminal et les donnees de con- 
tenu possedees par chaque dispositif terminal, et les 
informations d'attributs contenant I'adresse de cha- 20 
que dispositif terminal ; 

une unite de memoire (2, 5) configuree en vue de 
stocker les informations d'adresses et d'attributs de 
chaque dispositif terminal sur le premier reseau (1 1 ) 
et sur le second reseau (12), collectees par la pre- 25 
miere unite de collecte (2) et la seconde unite de 
collecte (5) ; 

une unite de commande d'affichage (2, 5) configuree 
en vue de permettre un affichage des informations 
stockees dans I'unite de memoire (2, 5) ; so 
une premiere unite de configuration (2, 3) configuree 
en vued'etabliruneconnexion en vue de transmettre 
des donnees de contenu a transmettre d'un terminal 
de transmission (1) a un terminal de reception (6), 
sur le premier reseau (11), apres reception d'une 35 
demande de transmission des donnees de contenu 
possedees par le terminal de transmission (1) d'un 
dispositif terminal sur le premier reseau (1 1 ) selec- 
tionne comme terminal de transmission (1 ) a un dis- 
positif terminal sur le second reseau (1 2) selectionne 40 
comme terminal de reception (6) selon I'affichage 
d'informations autorise par I'unite de commande 
d'affichage (2, 5), de sorte que I'unite de reception 
(3) recoit les donnees de contenu transmises par le 
terminal de transmission (1) en utilisant la 45 
connexion ; et 

une seconde unite de configuration (4, 5) configuree 
en vue d'etablir un canal en vue de la transmission 
des donnees de contenu a transmettre a partir du 
terminal de transmission (1), sur le second reseau 50 
(12), de sorte que I'unite de transmission (4) trans- 
met les donnees de contenu recues par I'unite de 
reception (3) au terminal de reception (6) au moyen 
du canal. 

55 

2. Dispositif relais selon la revendication 1 comportant 
en outre : 



une unite d'affichage (2, 5) configuree en vue 
d'afficher les informations stockees dans I'unite 
de memoire (2, 5) selon I'unite de commande 
d'affichage (2, 5). 

3. Dispositif relais selon la revendication 1 comportant 
en outre : 

une unite de decodage (3) configuree en vue de 
decoder des donnees de contenu codees re- 
cues par I'unite de reception (3), dans lequel 
I'unite de transmission (4) transmet les donnees 
de contenu decodees par I'unite de decodage 
(3) au terminal de reception (6) au moyen d'un 
canal. 

4. Dispositif relais selon la revendication 1 , dans lequel 
le premier reseau (11) est un bus IEEE 1394, et le 
canal est un canal de transfert isochrone IEEE 1394. 

5. Dispositif relais selon la revendication 4, dans lequel 
le bus IEEE 1394 qui constitue le premier reseau 
(11) est forme par des connexions en pont d'une 
pluralite de bus IEEE 1394. 

6. Dispositif relais selon la revendication 1 comportant 
en outre : 

une unite de commande (2) configuree en vue 
de commander le terminal de transmission (1) 
afin de transmettre les donnees de contenu en 
utilisant la connexion, lorsque le canal est etabli 
sur le second reseau (12) au moyen de la se- 
conde unite de configuration (4, 5) selon un mes- 
sage de commande recu par le dispositif relais ; 
le message de commande contenant au moins 
des informations relatives a une quantite requi- 
se de ressources de communication a un mo- 
ment de transmission des donnees de contenu 
sur le second reseau (12) et des informations 
d'en-tete a joindre aux donnees de contenu, afin 
d'etablir le canal sur le second reseau (12). 

7. Dispositif relais selon la revendication 1 , dans lequel 
la demande de transmission des donnees de conte- 
nu possedees par le terminal de transmission (1 ) est 
executee par un message de demande contenant 
des informations permettant d'identifier le terminal 
de transmission (1 ) de sorte que la transmission des 
donnees de contenu est commandee au terminal de 
transmission (1) identifie par ces informations. 

8. Dispositif relais selon la revendication 1 comportant 
en outre : 

une unite de commande (5) configuree en vue 
de commander le dispositif terminal de recep- 
tion (6) afin de recevoir les donnees de contenu 
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a transmettre en utilisant le canal lorsque le ca- 
nal est etabli par la seconde unite de configura- 
tion (4, 5). 

9. Dispositif relais selon la revendication 1 , dans lequel 
le second reseau (12) est un bus IEEE 1394, et le 
canal est un canal de transfert isochrone IEEE 1 394. 

1 0. Dispositif relais selon la revendication 9, dans lequel 
le bus IEEE 1394, qui constitue le second reseau 
(12) est forme par des connexions en pont d'une 
pluralite de bus IEEE 1394. 
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I'etape de permission, de sorte I'etape de reception 
recoit les donnees de contenu transmises par le ter- 
minal de transmission en utilisant la connexion ; et 
etablir un canal en vue de la transmission des don- 
nees de contenu a transmettre a partir du terminal 
de transmission, sur le second reseau, de sorte que 
I'etape de transmission transmet les donnees de 
contenu recues a I'etape reception au terminal de 
reception au moyen du canal. 



1 1 . Procede destine a commander un dispositif relais en 
vue de transmettre et de recevoir 
des donnees de contenu entre au moins un dispositif 
terminal connecte a un premier reseau et au moins 
un dispositif terminal connecte a un second reseau, 
le dispositif relais etant connecte au premier reseau 
et au second reseau et comportant les etapes con- 
sistant a : 
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recevoir les donnees de contenu transmises par 
le terminal de transmission, et 
transmettre les donnees de contenu recues a 25 
I'etape de reception au terminal de reception ; 

caracterise par les etapes consistant a 
collecter des informations d'adresses et d'attributs 
de chaque dispositif terminal connecte au premier so 
reseau, en demandant au moins I'un d'un type de 
chaque dispositif terminal et les donnees de contenu 
possedees par chaque dispositif terminal, et les in- 
formations d'attributs contenant I'adresse de chaque 
dispositif terminal ; 35 
collecter les informations d'adresses et d'attributs de 
chaque dispositif terminal connecte au second re- 
seau, en demandant au moins I'un d'un type de cha- 
que dispositif terminal et les donnees de contenu 
possedees par chaque dispositif terminal, et les in- 40 
formations d'attributs contenant I'adresse de chaque 
dispositif terminal ; 

stocker les informations d'adresses et d'attributs de 
chaque dispositif terminal sur le premier reseau et 
le second reseau, collectees a I'etape de collecte 45 
dans une memoire ; 

permettre un affichage des informations stockees 
dans la memoire ; 

etablir une connexion en vue de transmettre des 
donnees de contenu a transmettre d'un terminal de 50 
transmission a un terminal de reception, sur le pre- 
mier reseau, apres reception d'une demande de 
transmission des donnees de contenu possedees 
par le terminal de transmission d'un dispositif termi- 
nal sur le premier reseau selectionne comme termi- 55 
nal de transmission a un dispositif terminal sur le 
second reseau selectionne comme terminal de re- 
ception selon I'affichage d'informations autorise a 
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